A conventional virtual machine monitor (VMM) executes on a computing system and presents to other software the abstraction of one or more virtual machines (VMs). Each virtual machine may function as a self-contained platform, running its own guest operating system (OS) hosted by the VMM and other software, collectively referred to as guest software. The guest software expects to operate as if it were running on a dedicated computer rather than a virtual machine. That is, the guest software expects to control various events and have access to hardware resources. The hardware resources may include processor resident resources, resources that reside in memory and resources that reside on the underlying hardware platform. The events may include interrupts, exceptions, platform events, execution of certain instructions, and so forth.
In a virtual machine environment, the VMM should be able to have ultimate control over these events and hardware resources to provide proper operation of guest software running on the virtual machines and for protection from and between guest software running on the virtual machines. To achieve this, the VMM typically receives control when guest software accesses a protected resource or when other events (such as interrupts or exceptions) occur. For example, when an operation in a virtual machine supported by the VMM causes a system device to generate an interrupt, the currently running virtual machine is interrupted and control of the processor is passed to the VMM. The VMM then receives the interrupt, and handles the interrupt itself or delivers the interrupt to the appropriate virtual machine. However, this switching between guest and VMM is an inefficient use of processor cycles.